4章 コンストラクションの重要な決断

この章の概要

ここでいう重要な決断、とはつまり以下のことである。

言語の選択

プログラミングの規約

テクノロジの波を見極めること

この章については、具体的な内容については情報が古い部分もあったのでより一般化できそうな、抽象度の高い部分だけ抜粋する。

現場に向かう前にトラックに荷物を積み込む方法について説明する

4.1 プログミング言語の選択 のまとめ

使い慣れた言語を使うと生産性が高い

高級言語の方が低級言語より生産性が高い

特定の言語の特徴がプログラマの考えに影響を与えてしまうことがある

これによりその言語の特徴に偏った表現でコーディングしてしまうことがある

もちろんこれは弊害を生む

ここは「うんうん」という感じの内容が続く。

Ada, アセンブラ, C, C++, C#, COBOL, FORTRAN, Java, JavaScript, Perl, PHP, Python, SQL, Visual Basic

触ったことない言語が多い、Ada知らなかった。

4.2 プログラミング規約 のまとめ

コンストラクションを開始する前に「プログラミング規約」を細かく決めよう

これはソフトウェアの鉄則である「複雑さへの対処」にも通ずる

設計と規約の整合性が取れて初めて高品質なソフトウェアと言える（絵画の例え）

以下抜粋など

高品質なソフトウェアはアーキテクチャの概念的な整合性とその実装の間に関連性を見出すことができる

変数名、クラス名、ルーチン名、フォーマット規約、コメント規約などの規約にも整合性が生まれるとのこと。

プログラミングを成功させる鍵は、自由裁量によるばらつきをなくし、ばらついていて当然の部分に思考を集中できるようにすることだ

この話は次章の「5.2.1 ソフトウェアの鉄則：複雑さへの対応」へと続く重要なポイント

4.3 テクノロジの波に乗って のまとめ

テクノロジの波を意識して、自分が波のどこに乗っているのか自覚する必要がある

波の始まりなのか、成熟した波なのかによってプログラマの毎日の作業も変わる

もちろん考慮すべきことも変わる

言語の中でのプログラミングするな、言語の中へプログラミングせよ

簡素に言うとプログラミング言語にしばられた表現に囚われないという意味っぽい

Visual Basicでは奨励されていない書き方だが、規約を自分で作成したことで成功した例

言語の「中で」プログラミングしているプログラマは、自分の考えを、言語が直接サポートしている構造だけに限定してしまう。したがって、使用している言語ツールが初歩的なものであれば、プログラムの考えも初歩的なものになる。

それに対して、言語の「中へ」プログラミングするプログラマは、どのような考えを表現したいかを決めてから、その考えを特定の言語が提供するツールを使って表現する方法を決める。

特定の言語に表現を制限されないように、ゴールを決めてからそれを実現するための言語を選択する、という順番

この辺はプログラミング言語の表現力も向上しているし、各言語の特徴もこの当時よりはっきりしているので事情が変わっているかもしれない